Contemporary data processing activities are frequently distributed among a number of independent computer systems that use a communication fabric such as a local- or wide-area network to coordinate their operations. This model of data processing is generally more complex and somewhat less efficient than older arrangements where a complete, clearly-defined processing operation occurs at a single system and a “finished” data product may be transmitted to another location. In a distributed system, it is not uncommon for portions of closely-linked processing sequences to occur on different systems, with both partially-processed data and executable code passing between the systems over a communication link.
Various advantages are available from distributed processing. For example, computationally expensive or time-consuming operations can be consolidated and performed by a system designed specifically to perform those operations quickly; competing providers of standardized processing can establish a market to provide the services at a range of price/performance points; and decoupling phases of a processing sequence can make it easier to design robust systems that can continue operation despite failures of individual machines or communication links.
One difficulty that arises in designing and operating distributed data processing systems is in specifying the interfaces through which cooperating processing elements will communicate. Standards such as the Common Object Request Broker Architecture (“CORBA”) by the Object Management Group (“OMG”) consortium and the Web Services Description Language (“WSDL”) by the international World Wide Web Consortium (“W3C”) provide a great deal guidance in this area, but even assuming that all interoperational difficulties that are common to distributed systems could be addressed by the standards, individual distributed service clients and providers must agree even more closely on the methods and meanings of their interactions.
Computer programs and services have traditionally been identified by a numeric version number, and changes dealt with on an ad hoc basis. In one common usage, a two-part number describes the “major” and “minor” versions (e.g. version 2.6). A change in minor version number usually indicates that, while something has changed, the program or system can be expected to continue to work as it did in the past. A new major version number sometimes means that incompatibilities may be encountered. Version-number-based change management may be adequate for calling attention to the fact that a change has occurred, but in many environments, there is no standard mechanism for finding out more about the change. A user or system administrator may have no choice but to embark on a time-consuming search for further details, and there may be inadequate certainty that any details located represent the best and most-current information available. This approach has obvious drawbacks even when the number of services is small, and it quickly becomes untenable when applied to a larger number of services from a diverse group of providers. Alternate methods of obtaining information about changes to distributed data processing services may be of use in many environments.